Revision 571: TypeScript 5.1

Transcript

[0:00] Man kann halt nicht HTML und Type-Checking unter einen Hut bringen, weil diese ganzen Strings, die halt eben letztlich HTML und auch DOM zu einem gewissen Teil ausmachen, da ist halt relativ wenig Value rauszuholen.
Dir gab es bislang das Problem, dass TypeScript dich gezwungen hat, dass du auch tatsächlich explizit undefined zurückgibst.
Und diese Regel wurde jetzt ein wenig aufgeweicht.

[0:29] Music.

[0:55] Working Draft, Revision 571, und fürs weitere Zuhören.

Revision 571: TypeScript 5.1

https://workingdraft.de/571/

[1:27] Hallo und herzlich willkommen zu Working Draft Revision 571.
Heute am Starte der Stefan.
Hallo. Und meine Wenigkeit, der Peter. Und das kann nur eins bedeuten.
Auf unserem Zeitstrahl wurde jetzt gerade die neueste TypeScript-Beta angesagt.
Und zum Zeitpunkt der Veröffentlichung sollte im Prinzip die neueste TypeScript-Version 5.1 raus sein.
Und wie immer müssen wir uns da mal durch die Neuheiten und die sonstigen Ereignisse in der TypeScript-Welt einmal durchwühlen.
Und, ja, das machen wir, und ich würde sagen, wie immer, wühlen wir einfach einmal durch die angekündigten Features durch und sagen, was wir davon halten.
Und dann streifen wir ab.

[2:07] Ja, oder schon mittendrin, das kann natürlich auch passieren. Gleich mal als Disclaimer, ich sehe die Releasen heute zum ersten Mal, also tatsächlich war ich da immer viel Zeit nachher dran.
Ich habe tatsächlich zwei, drei Dinge gesehen, die sehr interessant sind, auf die ich mich schon lange freue.
Aber ansonsten ist, glaube ich, der Release relativ überschaubar. Also, es ist jetzt im Takt da, aber die großen Überraschungen, Neuerungen bleiben jetzt da.
Ja, es ist langweilig, was ich eigentlich gar nicht so schlecht finde.
Weil, ich meine, man hat's ja teilweise heutzutage nicht ganz so leicht zu rechtfertigen, dass man TypeScript verwendet.
Weil es ist ja tatsächlich ein weiteres Ding in so einer Toolchain, und das könnte Breaking Changes bekommen und irgendwie verschwinden, weil das von einer Firma eingestampft wird oder, oder, oder.
Und je langweiliger und je abgehangener das wird, umso besser ist das.
Ich meine, Langeweile ist im Prinzip die beste Versicherung nach Webstandard.
Sind das tatsächlich Diskussionen, die geführt werden?
Also gerade in Bezug auf Typescript, ich kann mir das vorstellen, große Firma und sehr moderne Technologie, kann man durchaus vorstellen, dass die Diskussion geführt wird.
Aber jetzt für Typescript, führt man das wirklich noch?
Ja, schon. Ich glaube, das kommt sehr stark darauf an, welchen Ausschnitt der Realität du so wahrnimmst.

[3:25] Also wir zwei hier kochen natürlich da schon sehr stark in der Suppe, die Typescript tatsächlich jetzt so ungewöhnlich nicht findet.
Aber es gibt halt durchaus Leute, die sehen da relativ überschaubar viel Wert drum, beziehungsweise für die ist der Trade-off zwischen noch ein extra Tool und noch ein extra Bildschritt.
Und es ist ja teilweise auch bei einer großen Codebase echt ziemlich langsam manchmal.
Das könnte man sich im Prinzip ja einfach alles ersparen. Das ist ja auch nicht verkehrt.
Nein, total. Also die Entscheidung kann man ja treffen.
Also ich kenne auch tatsächlich Firmen, die jetzt gesagt haben, okay, wir reduzieren den Effort, den wir in TypeScript stecken, wieder um einiges.
Um einiges, was nicht heißt, dass Sie TypeScript komplett aus dem System streichen, aber man geht halt nicht mehr all-in, man verwendet jetzt eine Typ-Annotation homöopathischer oder horcht oft einfach nur auf JS-Doc-Kommentare und ist happy genug, das ist total legitim.
Das denke ich bei dem auch.

[4:21] Und das ist ja auch per se nicht die verkehrteste Idee zu sagen, das richtige Tool für den jeweiligen Job rauspicken.
Ich mach das ja immer so andersherum kommend, wenn ich den Leuten so erzähle, hier, Web Components, alles ganz toll, und sie mich fragen, was sind so die größten Nachteile, ist halt einfach so, man kann nicht HTML und Type-Checking unter einen Hut bringen.
Es gibt halt entweder das eine oder das andere, weil diese ganzen Strings, die HTML und auch DOM zu einem gewissen Teil ausmachen, da ist relativ wenig Value rauszuholen.
Ja, und wenn du dann auch noch hingehst und du sagst so, okay, ich baue jetzt meine Web-Components mit irgendwie den neuen schönen Decorators von der letzten Typescript-Version zusammen, was ja tatsächlich geht, die kann man sich ganz gut bauen und dann kann man tatsächlich so Komponenten zusammen komponieren, das geht ganz gut, aber das ist ja der erste Tweet, den ich zu Decorators in Typescript jemals gesehen habe, der war ja von dir, wo du sagtest, oh mein liebes Anni, das ist ja tatsächlich ganz schön viel Aufriss, den man da betreiben muss, um das irgendwie typesafe zu machen oder man lässt es halt gleich bleiben.
Und wenn man dann den ganzen Aufriss betreibt, weil es gibt ja nicht irgendwie die etablierte Decorator-Library.
Und dann kriegt man halt hinten trotzdem die Information raus, ja, das ist Annie, man weiß es nicht. Ja, ja, das ist eigentlich schon.

[5:30] Also rückwirkend betroffen, das ist jetzt, glaube ich, schon zwei Revisionen her oder so, dass wir über die Decorators gesprochen haben.
Also zwei Revisionen mit uns. Es ist schon ein starkes Stück eigentlich, dass du sagst, hey, ja, wir empfehlen, nicht zu viele Types zu verwenden, damit das Ding irgendwie anständig bedienbar ist.
Ansonsten kommt sich TypeScript wunderschön selbst in die Quere mit dem Aufwand, der betrieben werden muss, um einen Dekorator zu schreiben, der mehrfach verwendbar ist.
Also das ist, ich finde es beeindruckend. Ich muss natürlich sagen, ich habe die Dinger bisher immer geschrieben für Web Components.
Das heißt, es gibt ja ein relativ eingegrenztes Einsatzspektrum, sprich die Basisklasse ist immer HTML Element und dann kriegt man es halt schon mit vertretbar viel Aufwand, so einigermaßen type-safe her und das ist natürlich auch ganz schön, von der anderen Seite kommt, wenn man so ein Ding tatsächlich irgendwie aus so einem Template her erst mal raus klont und man sagt so, dass es jetzt irgendwie ein Decorator für, keine Ahnung, ein.

[6:26] Ein Getter und Setter abgedönst für einen Accessor. Und du weißt, das Ding inherited erst mal von so HTML-Elementen, und dann kannst du dir eine Art Template bauen, dass du copy-pasten kannst.
Und dann ist es schon ganz gut, wenn du das dann hast und halt eben auch bei den Decorators zum Beispiel weißt, yo, Context hat jetzt diese und jene Shape, und das geht alles.
Ich hab tatsächlich kurz bevor du gekommen bist, probiert, so einen Decorator aus dem Kopf in JavaScript zu schreiben.
Okay, value Context, die Parameternamen wusste ich noch, Ja, nein, das verstehe ich.
Und deswegen, man kann es so oder so machen. Ich glaube, da fehlt mir mittlerweile auch ein bisschen die Regelmäßigkeit, in der ich solche Decorator schreibe, weil ich doch tatsächlich sehr wenig TypeScript außerhalb vom Serverless-Kontext schreibe, wo es jetzt nicht unbedingt gang und gäbe ist, dass man das verwendet.
Und ich glaube, wenn ich mehr drin wäre, würden wir die Parameterlisten abdesignen bzw. die nötigen Typen dranhängen können, damit ich weiß, was das für ein Kontext ist.
Boah, ich weiß nicht. Die Tabelle ist so kompliziert.
Okay. Ich habe für einen Workshop wirklich mal gesagt, ich mache jetzt einen Slide mit einer Tabelle drin, wo man wirklich so sehen kann, wenn Decorator für diesen und jenen Zweck plus halt eben noch aufgeteilt in Public und Private, dann ist es jener Value und jener Kontext und das hat diesen und jenen Wert und dann gibt es ein Initializer-Ja-Line vielleicht.

[7:50] Cool. Cool. Coole Tabelle. Ja, nein, überhaupt nicht, weil die Schriftgröße musste so klein sein, dass er hinterher nur noch als Witz taugte.
Aber das illustriert halt nur meinen Punkt, dass das halt tatsächlich so kompliziert ist, dass das irgendwie ...
Also, weißt du, so was wie Yeoman früher, dieser Code-Generator, wo man irgendwie so einen Assistenten, im Prinzip hatte, der hat einen gefragt, willst du dieses, jenes, solches, so oder so oder so?
So was für Decorators wäre tatsächlich jetzt nicht ganz so irre.
Ein VS Code Wizard. Ja, weil es ... Durch die Erstellung vom Dekorator führt.
Ja, es könnte halt eben auch eine Webinterface sein, wo du halt irgendwie so, wie bei How to send this in CSS, früher einfach sagst, JavaScript, Typescript, ja, nein, das soll sein für ein Feld oder eine Methode. Privates, ja, nein oder beides, weißt du?
Ja. Und dann wird ein Template draus, wo du hinterher deine Logik einführst.
Ja, oder man macht Dekorators Das ist einfach nett.

[8:48] Oder man macht sie halt selten. Das wäre ja eigentlich die Idee, dass man sich das zusammenkomponiert.
Ja, ja, durchstimmt.
Aber das ist halt so ... Ich weiß ja nicht, wie das so dein Eindruck ist, aber ich hab von den Dingern jetzt relativ wenig gesehen.
Die sind halt da, wo sie vorher auch schon waren, in diesen ganzen ORMs und Zeug.
Aber das jetzt so verglichen mit früher, als React um die Ecke gekommen ist und gesagt hat, hier, Hooks, und alle so, ah, guck mal, implementiere ich jetzt für dieses, jenes, solches, Zumindest habe ich den Eindruck, dass das Interesse dort sehr überschaubar ist.
Ja. braucht's.
Da braucht's irgendein populäres Framework, das einmal anfängt damit.
Und dann sagt, hey, und wisst ihr, ihr könnt eure Funktionalität so und so hinzufügen, und dann passiert das.
Aber das ist natürlich in der Welt des Welts und Reacts und Solids, ist das halt nicht der Fall. Ja.

[9:43] Das notwendige Paradigma ist halt nicht en vogue, das ist das Ding.
Ja, genau. Genau. Ist fast schade.
Ich find's interessant, es gibt sehr viel Diskussion zu dem Punkt, Komponenteninstanzierung in diesem Frameworks funktioniert oder in dem Frameworks unterschiedlich funktioniert und tatsächlich nimmt sich jedes Framework heraus. Die Grundidee von so einer Komponenten, dass du mehrere Instanzen hast, die unterschiedlich gerendert werden, nimmt es ja weg. Also das macht ja React mit Hooks und Function Components genauso wie wie das Welt mit den Single-Files, Welt-Files und so weiter. Also tatsächlich, dass du sagst, du generierst eine Schablone und mehrere Instanzen davon, ist nicht mehr so. Das schaut nur so aus, wie wenn wir das so schreiben würden, aber die Realität dahinter ist eine andere. Und da hat sich der Yehuda Katz vom Ember-Framework vor etlichen Jahren einmal erbrüstet und hat gesagt, wir hätten ja eigentlich Tools für mehrere Instanzen des gleichen Dings. Warum nimmt es denn keiner?

[10:49] Weil es schürch ausschaut? Oder was ist tatsächlich der Grund? Und das wäre natürlich ideal. Und da muss ich ganz ehrlich sagen, schauen wir mal das Klima-Framework-Auto, die Klima-Library, falls du das noch nicht gesehen hast. Das ist der Unterbau von Ember jetzt. Das geht, glaube ich, wirklich so in die Richtung, in die man gehen möchte. Also das schaut richtig, richtig cool aus.
Ja, ich meine, der Yehuda Katz war ja auch derjenige, der von Anfang an einer der allerersten Decorators, Befürworter war. Der hat ja, glaube ich, wirklich so das allererste Proposal geschrieben vor, keine Ahnung, in der Ober- und Kreidezeit oder wann das war.
Ja, ganz genau. Und der Yehuda Katz ist auch sehr bekannt dafür, dass er sie wirklich nur nur solange in...
In so eine Sache einbringt, solange er auch noch Sinn sieht, dass das tatsächlich weiterkommt. Und er hat das halt getrieben bis zu dem Punkt, wo jeder gesagt hat, Export jetzt davor oder danach. Und ...

[11:44] Tja, schade. Ja, ich meine, wie gesagt, es gibt ja ein so ein Sektor, in dem ich sagen würde, das mit den Decorators geht da nicht weg.
Das sind halt die Webcomponents, weil da die Klassen nicht weggehen.
Tatsächlich da etwas, was die Dinger sehr weit nach vorne bringen könnte.
Weil irgendwie so eine generische Idee eines Attribut-Decorators, wo man einfach so sagen kann, hier hast du Accessor, und das wird dann halt eben auch in einem Attribut reflektiert.
Das hieß damit tatsächlich, unendlich viel Aufwand zu machen, und das müsste man halt auch nur einmal ordentlich machen, und dann ginge das.
Aber ich wüsste halt sonst auch nicht, wo irgendwie Klassen verwendet werden, außer halt in den, wie gesagt, den ganzen ORMs.

[12:27] Schauen wir mal. Mir fällt tatsächlich auch nichts gescheites ein, aber...
Nö. Vielleicht muss das erst noch sich durchsetzen. Das setzt sich bestimmt durch.
Okay, was anderes, was sich durchsetzt, ist TypeScript. Ja, genau. Also, wo wir wieder beim Thema wären.
Genau, TypeScript 5.1. Ich hab immer noch gesagt, dass wir eventuell leicht abschweifen werden.
Naja. Aber hier, du hast doch sofort gesagt, das erste Feature hier auf der Liste ist ein ganz großartiges, Weil jetzt eine Function, die undefined returnt, jetzt auch undefined returnen kann, selbst wenn man nicht dran schreibt, dass sie undefined returnt, sondern was anderes, was wie undefined ist, aber anders.
Richtig? Gehen wir es vielleicht noch mal Schritt für Schritt durch.
Es gibt ja diesen fantastischen Umstand, dass eine Funktion in JavaScript tatsächlich immer irgendwie einen impliziten Return-Wert hat.
Und zwar, wenn kein Return-Wert stattfindet, dann gibst du undefined return zurück.
Ist jetzt wahrscheinlich nicht zu hundertprozentig richtig, weil du halt ein Binding hast oder einen Wert hast, der halt nicht gesetzt wird, aber wenn du jetzt sowas hast, wie let x ist gleich fu und fu gibt nichts zurück, dann ist der Wert von x und ich müsste es eigentlich ausprobieren, wenn ich den Wert schon auf zwei gesetzt habe und nachher weise ich den auf eine Funktion zu, die keinen Rückgabewert hat, dann müsste es tatsächlich auch wieder undefined sein.

[13:49] Das wäre jetzt meine Erwartung. Und tatsächlich gibt es unterschiedliche Möglichkeiten, diesen Rückgabewert explizit auszuzeichnen. Du hast die Möglichkeit, dass du das über Void auszeichnest. Das ist quasi ein Substitut für Undefined und das wird tatsächlich auch als Substitut behandelt.
Sprich, du kannst über dieses sehr unbekannte Feature namens Substitutability auch Funktionen.

[14:19] Zuweisen, die statt void etwas anderes zurückgeben. Und TypeScript sagt einfach, na gut, du gibst mir jetzt zwar eine Funktion, die ein Number zurückgibt, aber ich behandle sie als void, das heißt, du kannst nachher mit diesem Wert nichts anfangen. Ganz, ganz wichtig für Callback-Funktionen.
Die zweite Möglichkeit ist, dass du sagst, du hast den Rückgabewert any, any ist halt alles, das heißt auch void, deswegen ist es auch wieder wurscht. Und die dritte Möglichkeit ist, dass du sagst, du gibst undefined zurück, also den Rückgabewert undefined. Und hier gab es bislang das Problem, dass TypeScript dich gezwungen hat, dass du auch tatsächlich explizit undefined zurückgibst.
Und diese Regel wurde jetzt ein wenig aufgeweicht, wenn ich es richtig verstanden habe.
Ja. Genau.
Genau, weil ich meine, so ein bisschen ist das ja so ein Scherz, den ich immer ganz gerne in irgendwelchen Workshops oder Vorträgen verwende, TypeScript besser ist als JavaScript, weil in JavaScript gibt es zwei Möglichkeiten zu sagen, etwas ist nichts, nämlich null und undefined. Und in TypeScript gibt es drei, nämlich null, undefined und void. Und mehr ist mehr als weniger und deswegen ist TypeScript besser.

[15:30] Und das trifft halt jetzt nicht mehr ganz so sehr zu, weil ja sozusagen kein beobachtbarer Unterschied zwischen void und undefined besteht, wenn man das jetzt mal auf JavaScript runter bricht. Ja, es gäbe nur diesen einen Unterschied noch, der mir besonders gefallen würde, nämlich der, dass du undefined nicht substitutable machst.
Das heißt, du kannst dann sagen, hey, du hast dort zwar diese callback-Funktion, du erwartest, dass sie void zurückgibt, dann kannst du auch eine Funktion reinstecken, die zum Beispiel number zurückgibt und das funktioniert.
Wenn du allerdings erwartest, dass die Funktion undefined zurückgibt, dann dürftest du die nicht mehr mit einer number-Funktion substituten können.
Das wäre meine Erwartung. Ich habe das jetzt noch nicht ausprobiert.
Ja, würde mich jetzt auch nicht wundern, wenn es so wäre. Andererseits macht es ja trotzdem keinen Unterschied.
Weil solange du ja sagst, ich lebe in einer Welt, in der da undefined zurückkommt, wenn das eine Welt ist, in die dann auch Number reingesteckt werden kann, kannst du ja trotzdem nicht ran.
Mit Welt meine ich halt jetzt einen Scope. Ja, das stimmt. Ist ja mit Void genauso.
Das stimmt. Das ist aber wieder nur in diesem ...

[16:34] In der inneren Typescript-Welt, wo alles typsafe ist und alle einer Meinung sind, was die Typen angehen.
Wenn du aber dann wieder an der Grenze zur Echtwelt bist und vielleicht mit Nutzeingaben zu tun hast oder tatsächlich mit den Wert noch irgendwo weiterschleppst und die irgendwo landet, wo er nicht landen soll, dann ist das wieder problematisch.
Verstehe ich nicht ganz, weil es macht ja keinen Unterschied, ob sozusagen dieses Phänomen auftritt unter der Annahme, es käme aus der Callback-Funktion Void zurück oder unter der Annahme, Ischemo aus der Callback-Funktion undefined zurück.
Weißt du? Die Annahme ist ja, wir haben void oder undefined.
Und Substitutability heißt halt, kann ich da jetzt dann 42 über den Umweg des Callback-Funktions-Return-Werts reinstecken?
Ja, nachher vielleicht.
Ist ja egal, welcher Illusion ich anhänge, die dann unterlaufen wird.
Okay. Und dann hast du dann noch ein if-Statement, wo du überprüfst, ob der Wert eine Zuweisung hat.
Und triggerst eine Logging-Line ansonsten nicht. Ja.
Und dann kommen diese Login-Lines, und damit meine ich jetzt nicht einfach nur Console.log, sondern tatsächlich irgendwie Telemetry.
Oder du musst irgendeinen Wert abschicken oder du musst irgendeine Operation beenden, was auch immer das ist.
Mein TypeScript würde wahrscheinlich sagen, hey, das ist immer wahr oder das ist immer falsch.
Aber tatsächlich kannst du dort in einer Condition laufen, wo du sagst, nö, das könnte problematisch sein.

[17:55] Genau, es könnte sich halt immer zur Laufzeit noch anders ausprägen, als es zur Compile-Zeit dargestellt wird. Aber ich meine, der Punkt, warum wir da so ein bisschen am Wabern sind, ist halt eben der Unterschied zwischen Void und Undefined, der war ja vorher schon sehr klein.

[18:10] Und jetzt wird er halt noch kleiner gemacht. Ja, was Gutes. Also, ich find das ...
Also, ich hab immer Void so als lockeres Undefined gesehen und tatsächlich als Subtypen von Undefined behandelt.
Also, ich find, die gehören einfach viel stärker zusammen als jetzt zum Beispiel Void in einer anderen Programmiersprache oder der leere Typ in Rust oder was auch immer. Genau. Die Frage ist halt nur, sollte man noch Void haben wollen?
Also sollte ich jetzt noch Code schreiben, in dem meine Funktion sagt, ich returne Void versus Undefined?
Wenn du substituten willst. Letzteres ist ja sozusagen die präzisere Beschreibung der Realität.
Und das ist ja eigentlich das, worauf ich immer so ein bisschen auswill.
Wenn du Undefined substitutable machst, dann gibt's keinen Grund, beides zu haben.
Mh.

[18:55] Finde ich. Hätte ich jetzt auch gesagt. Ja.
Weil, wie du völlig richtig sagtest, Void in TypeScript ist immer schon so ein bisschen so ein ...
Also passt nicht so ganz auf diese Welt drauf.
Ist, glaub ich, auch noch so ein Überbleibsel aus der Metadon- für Enterprise-Entwickler-Historie von früher.
Ja, garantiert.
Also, dass Void als Rückgabewert so genommen wird, ist sicher stark inspiriert von C Sharp.
Und man hat halt versucht, wie so oft in TypeScript in den frühen Tagen.

[19:23] Das Konzept aus C Sharp irgendwie auf Javascript zu meppen, wo man nachher draufkommt, hey Moment, es gibt auch einen Wald in Javascript.
Tatsächlich macht das aber auch ganz was anderes. Das einzige, was es macht, ist, dass zum Schluss nichts zurückkommt.
Also quasi so als Blockade von der Expression danach, es wird auf jeden Fall undefined zurückkommen.
Ja, nicht Blockade, ne? Weil ich meine, es wird ja schon die rechte Seite evaluiert, und das Ergebnis wird verworfen.
Also eine Blockade wäre jetzt ja im Sinne von, wird nicht evaluiert, aber wird's ja.
Also ich sehe, dass der Rückgabewert nicht zugewiesen werden kann.
Das heißt, du hast so ein kleines Schlüsselwort davor, das dir einfach sagt, egal was rechts passiert, das kommt nicht durch auf die linke Seite.
Genau. Ja. Einziger Use Case ist eine kürzere Form von undefined schreiben für die Minifier, oder?
Void 0, oder? War das das? Ja. Es könnte auch Void 7 sein. Das macht ja, wie gesagt, keinen Unterschied.
Ja, ja. Ich habe aber, warte mal, ich suche das jetzt raus. Ich habe nämlich tatsächlich vor Äonen einen Artikel geschrieben über Void in JavaScript, was man damit machen kann.
Also tatsächlich hast halt du so eine Möglichkeit gehabt.

[20:33] Einen Funktionsnamen zu definieren, mit dem du aber den globalen Namespace nicht, pollutest, habe ich geschrieben. Ich weiß jetzt nicht, was das deutsche Wort dazu ist, also keine globalen Namespace-Verschmutzung durch irgendwelche Namen. Und was auch ja auch interessant war, ist, du kannst nicht einfach sicher sein, dass wenn du jetzt zum Beispiel mit Aero-Functions arbeitest, die ja quasi einen Rückgabewert haben, dass du sagst, ja gut, egal was da reinkommt, du wirst auf jeden Fall nicht, dass der Rückgabewert rauskommt.
Ich schreibe das auch in unsere Notes rein. Gibt ein paar minimale Use Cases, die, glaube ich, ganz interessant sind.
Aber du hast recht, das meiste wird von Minifiers verwendet.
Ja.
Also eines Tages möchte ich ja mal irgendwo ein Pull-Request unterbringen bei irgendeinem Minifier, der dann so irgendwie so aus Void 0 Void 1 macht. Und dann kann ich sagen, ha, hier, off by one, weißt Bescheid.
Ist das dann ein Breaking Change? Ähm, ich bin sicher, dass das irgendwelche regulären Ausdrücke von irgendwelchen nachgelagerten Skripten kaputtmacht und dann ...
Garantiert.

[21:38] Ist das alles eine große Katastrophe. Ja. Ähm, erstes Feature, cool. Ja. Erledigt.
Zweites Feature. Das ist auch ... Wir haben ja schon in der Vorbesprechung gesagt, wir sind jetzt so auf einem Level langweiliges Release.
Aber Dinge, wo wir gesagt haben, Gut, dass die drinnen sind. Entweder die enthusiastische Art. Wow, endlich ist das Feature so.
Die nicht so enthusiastische Art. Naja, endlich ist das Feature so.
Und ich glaube, da fällt das Zweite rein, weil ich hätte jetzt da, also wenn man es so lest, denke ich mir, hätte ich eigentlich jetzt da erwartet.
Also die unterschiedlichen Typen für Getter und Setter. Also ich glaube, die gibt es eh schon ein bisschen später, ein bisschen länger schon, was du jetzt sagst, du kannst jetzt...

[22:31] In einem Setter mehr Typen angeben, als wie im Getter oder umgekehrt.
Mhm. Was ist jetzt das Neue?
Naja, vorher mussten die Typen, die du im Getter und Setter als Rückgabewert im Getter und als Parameter im Setter hattest, die konnten unterschiedlich sein, aber die mussten zumindest Gemeinsamkeiten haben.
Okay, sie brauchten eine Schnittmenge. So ist es.
Und das ist jetzt nicht mehr der Fall, weil es halt diverse DOM-APIs gibt, Zum Beispiel die Style-Property im DOM.
Die ist ja auch ein Getter-Setter-Paar.
Und das ist ja komplett schräg, wo man da irgendwie Strings reinsteckt und CSS-Rule-DOM-Objekte rausbekommt. Oder umgekehrt.
Die haben auch nichts miteinander zu tun. Und siehe da, diese Steinalter-API wird jetzt endlich mal korrekt durch TypeScript modellierbar gemacht, indem gesagt wird, Getter und Setter, ach wisst ihr was, eure Parameter und Rückgabetypen, die müssen nichts miteinander gemeinsam haben.
Ist das hinterm Fleck? Äh, ich glaube nicht, ich meine, nichts davon gesehen zu haben.
Nö.
Warte mal. Tätätätätä. Äh, nö. Okay.
Also, ähm, selten der Fall, dass, ähm, API sich komplett verändert von Release zu Release und das nicht hinterm Flag ist.

[23:50] Ja, also ... Weil ... Ich meine, das macht jetzt ja nichts kaputt.
Das macht ja sozusagen nur ...
Es wird lockerer. Mit dem hab ich nicht gerechnet.
Ja gut, aber ist das nicht mit der Void-Geschichte auch so, dass das lockerer geworden ist?
Eigentlich schon, ja.
Ja, von daher, es ist lockerer geworden, aber in sozusagen dem Rahmen der Lockerheit wird's halt korrekter. Richtig, ja.
Bezogen auf das, wie es halt wirklich ist. Andererseits würde ich halt eben sagen, wo ich bei den Undefined Functions wirklich sagen würde, jawohl, wunderbar, ich kann jetzt auf Void verzichten, bin ich mir halt nicht so sicher, ob's eigentlich so valide Non-Legacy-Use-Cases gibt für Getter und Zetter, wo die ganzen Typen wirklich überhaupt gar nichts miteinander zu tun haben.

[24:33] Ja, außer die DOM-APIs, wie wir gesehen haben. Das würde ich unter Legacy-Use-Case einsortieren.
Weil ich finde es schon ein bisschen seltsam, wenn du die Style-Property im DOM verwendest, wenn ich mich erinnere, musst du dir ja einen String geben, dem musst du ja so eine CSS-Deklaration geben, und dem kannst du keine CSS-Style-Rule geben.
Was echt ein bisschen seltsam ist. Klar, es gibt keine vernünftige API, um so eine CSS-Style-Rule zu erschaffen, aber wenn es eine gäbe, könnte man mit den Dingern nichts anfangen, weil man sie nicht in Style reinstecken kann.
Das ist, weil die wenigsten Klassen im DOM instanzierbar sind von dir.
Sondern das rendere sich wie irgendwelche Factorys.
Ja, das ... Und die Factory ist wie so eine CSS-Style-Declaration, ist tatsächlich der Setter bei dem Element, ne?
Ja, also ich meine, es gibt ja mittlerweile diese Constructable-Style-Sheet-Dinger.
Ja. Jetzt weiß ich natürlich nicht, was Existenz heißt, aber ich seh grad hier Browser Support, Chrome, Firefox, alle da.

[25:29] Safari ebenso. wunderbar. Das geht halt jetzt doch schon, aber die benutzt ja niemand für irgendwas.
Ja, also und naja, also wenn es jemand nutzt, dann wahrscheinlich in irgendeiner Bibliothek, auf der du aufbaust. Ja, genau. Aber sei es, wie es sei, der Grund, warum das jetzt sozusagen ja gemacht wird, ist ja tatsächlich, ich meine, die Begründung ist ja vor allen Dingen tatsächlich, dass es diese Legacy-APIs gibt, und hier frage ich mich halt eben schon, ob es tatsächlich irgendwelche gültigen Use-Cases gibt.
Also willst du eine Klasseninstanz haben, wo du aus dem Getter was rausbekommst, irgendwie einen Typ X, den du nicht in den Zeta reinstecken kannst?
Mhm.

[26:14] Ich kann mir vorstellen, dass du im Zeta irgendwie mehr zulassen willst, weil du es halt intern konvertierst.
Ja. Aber dass du es überhaupt nicht akzeptieren willst, dass du es ablehnen willst, finde ich schon eher exotisch. Ja, das stimmt.

[26:30] Also ich könnte, also ich als Entwickler könnte mir keinen Anwendungshall aktuell vorstellen.
Wie, es sei denn, es wäre halt irgendwie so eine Converter Factory, wo du irgendwie sagen kannst, ich mache aus A B und aus B mache ich A. Ja, aber dann hast du kein Get Down Setup.
Ja, sonst hast du das nicht. Und zweitens, selbst dann würdest du ja trotzdem irgendwie sagen wollen, da könntest du ja trotzdem ohne Probleme A A akzeptieren lassen.
Macht ja keinen Unterschied. Ja, vor allem ist das ja easy implementiert.
Würde ich jetzt meinen. Also ja, es ist eine sehr riskante Aussage, meine Herr, sowas zu sagen, aber da würde ich tatsächlich mitgehen in dieser Angelegenheit.
Ja, nächsten Punkt. Gehen wir zum nächsten Punkt, lieber. Komm, wir sind hier ja noch nie so schnell gewesen wie dieses Mal. Großartig.
Re-couple Type-Checking between JSX elements and JSX tag types.

[27:24] Ich muss ja tatsächlich sagen, so richtig, so richtig, äh ...
Also klar, ich hab verstanden, was die machen wollen.
So, dass man irgendwie, also im Prinzip sind ja JSX, Tags, Spitzklammer auf, irgendein Name, Spitzklammer zu, das Ganze ist dann die Ausführung einer Function, ist ja nur eine alternative Funktionsaufrufs-Syntax.
Ja. Und die ist aber sehr hart darauf, ähm, ausgelegt, dass das, was dann da rauskommt, einem bestimmten Typ entspricht, dem JSX-Element.
Und dass man dann zum Beispiel nicht so was bauen kann wie eine Funktion, die die JSX-Syntax verwendet, um einen Promise auf ein JSX-Element abzubilden.
Ja. Das geht nicht, obwohl halt so Sachen wie React und Consorten darüber nachdenken, ob das nicht vielleicht eine gute Idee wäre, wo ich mitgehen würde, weil es ist entweder eine alternative Aufrufs-Syntax für eine Funktion und nicht mehr, oder es ist irgendwas Spezielles.
Wenn wir uns dafür entscheiden, es ist die Aufrufs-Syntax, hat das gefälligst auch zu funktionieren mit Container-Typen.

[28:20] Und das ist im Prinzip jetzt eine Möglichkeit sozusagen dererlei abzubilden.
Ich würde das mehr so unter Infrastrukturmaßnahme einordnen, weil ich glaube nicht, dass das jetzt akut irgendwelchen Einfluss hat auf die Entwicklungsrealität.
Tatsächlich nicht. Sie haben schon gesagt, auch in dem Beitrag jetzt, React, was heißt Consider, auf Deutsch, also zieht in Betracht, das für Komponenten im Framework einzubauen, das heißt, du solltest...
Limited.
Ja, Limited. Keine Ahnung, was da limitiert wird. Wahrscheinlich wieder Hooks oder so, weil die halt einfach echt katastrophal eigentlich sind.
Aber das ist dann wahrscheinlich vorgegriffen und TypeScript tut's nicht weh.

[29:09] Also ich sehe da jetzt auch nicht wirklich den Grund, warum das jetzt nicht so existieren sollte.
Ich lese das halt mal so, React is considering limited, irgendwie so was.
Das ist irgendwie so was, wie, die wollen nicht wirklich Nein sagen.
Ja, das stimmt. Ah, apropos React und JSX, das ist jetzt nicht einmal in den Releasen, aber eine Sache, die ich interessant finde, und wo ich mir denke, hey, das könnte vielleicht was werden.
Es wird grad an so einem Factory-Hint-Proposal gearbeitet, das dir erlauben soll, dass du zum Beispiel nachschaust, wenn da irgendwelche Kinder erwartet werden, Kinder erwartet werden, welche Kinder sind denn das jetzt? Das heißt, du wirst dann endlich die Möglichkeit haben, dass du in React-Komponenten Children subtypen könntest. Ah, dass du also sagen kannst, ich akzeptiere Children, aber in meiner Foo-Komponente akzeptiere ich nur Bartchilder.
Genau, zum Beispiel. Das ist ja ein Feature, das Flow-Type schon seit ewig kann, weil in Anonynet ist das extra für das gemacht worden. Und diese Factory-Hints sollen dir die Möglichkeit geben, dass du das auch jetzt implementieren kannst für deine Komponenten.
Ist gerade mal eine Proposal, ist aber irgendwie auf der Roadmap für das nächste Release oder so, Also mal schauen, wird wirklich an Betracht gezogen.

[30:23] Ja, äh, sehr, sehr schöne Idee. Macht ja das Ganze noch, sagen wir mal, unwebbiger, als es ja ohnehin schon ist.
Ich sag ja mal, so React, so ein bisschen das Anti-Web-Framework.
Und wenn wir jetzt wirklich die Möglichkeit haben, also, ich meine, der gesamte Sinn hinter so einem Frontend-Framework wie React ist ja im Prinzip das Herstellen von API-Contracts zwischen Dinger, die normalerweise keiner haben, nämlich HTML-Elemente, die existieren und so.
Und das jetzt dann sozusagen darüber auch noch ein bisschen nicht, wenn man dann erst mal mitgeht, dass das irgendwie eine gute Idee ist, was sie da anstreben.
Ja. Nein, also ich finde gerade, also wenn ich mir wo mehr Type-Checking wünschen würde, dann dort.

[31:04] Kurzer Disclaimer, die Kinder kommen gerade nach Hause und meistens ist das immer mit Tränen verbunden. Das heißt, es kann sein, dass ihr bald einmal ein wenig Kinderweinen auf der Tonspur hört oder ich sehr abgelenkt bin das hört sich ja sonst bei mir auch immer so als wäre ich im katzenfolterzentrum heute ausnahmsweise mal nicht gesagt ich bin wahrscheinlich ein bisschen abgelenkt jetzt du alles gut alles gut aber ja also sagen wir so dass zumindest mal etwas was noch relativ offensichtliche lücke ist wo auch so leute in ihrer in ihrem alltag merken warum kann ich das nicht festlegen? Ich bezweifle stark, dass das wirklich zu irgendwelchen Verwerfungen in irgendeinem Projekt führt. Nein, das nicht. Aber tatsächlich wäre das oft. Also ich bin ja, gerade was GSX und so weiter angeht, ich schreibe das ja natürlich noch, aber ich bin viel mehr Konsument als tatsächlich Produzent von Komponenten. Also wir arbeiten mit einem Designsystem und tatsächlich haben wir in dem Designsystem schon auch die Anforderung, dass gewisse Kindknoten vorhanden sind, wenn du das irgendwie sinnvoll nutzen möchtest. Und aktuell ist die einzige Möglichkeit, die habe ich in die Doku schauen. Und das will man ja genau nicht. Also deswegen hat man ja statisches Type-Checking, damit du dir einen Blick in die Doku ersparst.

[32:22] Wenn du zum Beispiel nur wissen willst, was kann denn da jetzt rein. Und dort ein Autocomplete zu bekommen oder zu sehen, dass ich das falsche Ding verwende, hilft auf jeden Fall. Also genau Und außerdem ist ja Type-Checking da.

[32:35] Hm.

[32:37] Ja. Type-Checking wäre das eine. Das andere ist natürlich auch, in so einem Designsystem kann das ja auch so eine Sache von entweder oder sein.
Und man kann das auf alle Weise A oder B machen. Und wenn B, muss aber auch C gemacht sein, damit das richtig aussieht. Und ich vermute mal, das läuft dann auch, sagen wir mal, Type-Checkend dann auf der zweiten Ebene dann doch auch in Limitierung generell.
Eine ganz fundamentale Art, würde ich mal unterstellen. Kanal.

[33:03] Was sie außerdem bei React gemacht haben, ist, ähm, Namespaces in JSX-Attributen jetzt zu supporten. Mhm.
Ist das in normalem React supported? Also kann ich ganz normales React benutzen, um XML und mit Namespaces und Zeug zu schreiben?
Ich glaub, dass es einfach nur dem geschuldet ist, dass alles, also das React selbst oder die JSX-Transform von React, also dieser Compile-Step, einfach sagt, alles nach der Spitzenklammer bis zum ersten Leerzeichen ist ein String und das akzeptiert, und dass sich daraus ein Pattern ergeben hat, das ist meine Vermutung. Also ich höre davon tatsächlich zum ersten Mal. Entschuldige, ich habe kaum React ohne TypeScript gemacht und wenn das dort nie gegangen ist, habe ich es natürlich nicht gemacht. Also ich habe halt mal React-Komponenten verwendet, die Members von Objekten fahren. Also da ist der Tag Name dann foo.bar. Ja, ja gut, das habe ich auch schon verwendet. Und ich meine, dann wüsste ich jetzt nicht, warum das mit XML-Namespaces, also mit einem Doppelpunkt statt einem Punkt, nicht gehen Das kommt aus XML.
Äh, ja, sicher. Vielleicht hat er einfach Enterprise React für sich entdeckt.
Und er hat gesagt, jetzt können wir es endlich verwenden.
Das war genau das eine missing Feature.

[34:32] Ja, die Idee ist ja jetzt nicht so bescheuert. Ich meine, einerseits ist das halt irgendwie so, ja, wir sind hier das Anti-Web-Framework, und so Sachen wie irgendwie XML-Namespaces sind uns irgendwie egal.
Möglicherweise, vielleicht, keine Ahnung. Und auf der anderen Seite aber trotzdem XML-Zutaten zu entforsten.
Keine Ahnung.
Ist halt nur so, man kann jetzt in Typescript eben Namespace-Attribute, also irgendwas Doppelpunkt, irgendwas anderes verwenden.
Ist für XML, also auch für SVG und Zeug ganz praktisch.
Man hat's halt vorher auch reinbasteln können, indem man halt Objektkeys genommen hat mit Doppelpunkten drin und die dann so reingespreadet hat.
Das ging auch schon immer, es ist halt einfach nur eine rein syntaktische Limitierung.
Mir würde echt interessieren, schreibt's uns auf Mastodon oder in die Webmanagements oder sonst wo auch immer, Twitter heißt das, was du suchst.
Twitter heißt das, genau. Wenn es das noch gibt, wenn diese Sendung veröffentlicht wird.
Ob ihr eine Anwendungshilfe für das habt.
Tatsächlich, ich sehe das, ich denke mir, ah cool, das geht.
Und dann denke ich mir, oh cool, will ich das verwenden. Und dann denke ich mir, nein, eigentlich nicht.
Danke, danke für das, dass es da ist. Aber, hm, hab jetzt nicht so den Bedarf noch.
Aber, hey, vielleicht fehlt mir da eigentlich die Verbindung zur Realität.
Die Verbindung zur SVG fehlt dir.
SVG ist doch sicherlich das XML-Ding, das so die weiteste Verbreitung genießt.

[35:51] Und XML-SVG in React zu schreiben, ist jetzt nicht so weit hergeholt. Hm ...
Naja, ich weiß nicht, ob ich ein SVG durch den Wirthold Dom ... jagen will.

[36:06] Vielleicht ist aber ... Du musst dir ja vorstellen, du bist ja nicht immer der Architekturastronaut, der frei entscheiden kann, was geht. der kleine Krauter, der an eine Aufgabe gesetzt wird, macht da dieses SVG-Icon rein.
Das musst du in React schreiben, das muss dieser und jenen Bedingung erfolgen, vorher, bla, ne, Zeug.
Du hast keine Möglichkeiten.
Dann ist ja die Idee nicht so fern, zu sagen, ich hab einen DOM, das muss nicht gedifft werden, aber ich hab keine Zeit und bin unterbezahlt, also ramm ich da mein SVG rein.
Wenn der sagt, syntaktisch mach ich nicht mit, weil er ist ein Doppelpunkt in meinem Attributnamen, ist das schon schwach.

[36:45] Also von daher, ja, passt halt. Ich glaube, React wird langsam auch so alt und abgehangen, dass das echt…, Wir nutzen React. Wir haben sich vor drei Jahren entschieden, dass React die neue Frontend-Technologie Ich wünsche Ihnen viel Spaß beim Nachmachen und bis zum nächsten Mal!
Ja, also wir sind schon im Enterprise angelangt. Jetzt ist es ja schon wirklich tried-and-trusted-technology.
Hey, mein Projekt hier ist auch React. Ich gebe keinen Tag, an dem ich nicht daran arbeite und darüber schimpfe.
Aber es funktioniert halt einigermaßen okay. Man darf halt nur nicht drüber nachdenken und nicht nachgucken, wie langsam das wirklich ist.
Da will ich News für dich, nämlich da kann ich dir sagen, wie die Enterprise-Perspektive drauf ist.
Ich hab Mitarbeiter, die gesagt haben, hey, wow, cool, endlich React.
Stunden von 30 auf 40. Das ist mal eine Aussage. Also so erfrischend kann es sein, mit React zu arbeiten.

[37:44] Was war vorher? Angular. Und vor Angular gab es GWT, das Google Web Toolkit.
Ja gut, das ist natürlich fies. Ja und ich muss ganz ehrlich sagen, wir haben Angular nicht gut behandelt, in der Zeit, in der es bei uns war. Inwiefern? Es war irgendwie von Start weg ein technical debt. Wir haben lahme Builds gehabt, die sind ja mal ein Dreivierteljahr abbestellt worden, um zu versuchen, auf einer Architekturebene die Applikation so neu zu gestalten, dass die Builds wieder schneller funktionieren. Es war alles ziemlich mühsam in der Entwicklung. Ich glaube, das ist aber nicht nur dem Framework geschuldet, sondern auch ein bisschen unserer Herangehensweise.
Eben gerade mit diesem Hybrid-Modus zwischen dem GWT-Altlasten und dem Angular-Neu-Code und so weiter, das haben wir jetzt, glaube ich, auf einer Architekturebene besser gelöst, weil wir einfach ein Greenfield-Projekt gehabt haben.
Ich muss dir einfach sagen, was passiert ist, wir nehmen jetzt das Projekt, weil wir eh nichts Altes irgendwie unterstützen müssen.
Und wir haben, das war schlau, architekturelle Entscheidungen im Fronten gemacht, dass wir auf ein Projekt wieder weg können, wenn es uns nicht mehr taugt.
Aber der Rest bleibt zumindest bestehen und funktioniert weiter.
Das war gar nicht so blöd.

[39:08] Aber dann würde es ja bedeuten, dass deine Kollegen, die sagen, ich mag jetzt wieder mehr Malochen, weil ich React habe, also da ist ja zumindest ein gewisser Teil dessen, wie es jetzt besser geht, auch dem geschuldet, dass die ganzen Altlasten weg sind.
Ja, wahrscheinlich. Wahrscheinlich ist es eher so, dass es am Greenfield liegt und nicht am Framework.

[39:32] Tja. Auch am Greenfield so an sich, ne? Aber es war ... Eben, eben.
Das war in der Umfrage sehr interessant gewesen. Warum glaubst du, ist die Zufriedenheit mit dem neuen Framework um so viel höher als mit dem alten? Woran liegt das? Weil wir haben wirklich guten Zuspruch gekriegt. Also ich bin ja nie der größte React-Fan gewesen. Ich habe mich halt damit beschäftigt, weil ich mich beschäftigen muss. Ich war aber nie so, dass ich gesagt habe, hey, das ist jetzt die einzige Art und Weise, wie man Web-Publikationen oder Webseiten stricken muss.
Wir haben aber nachher gesagt, für das Projekt, was wir dann angegangen sind und für die Lösung, die wir machen wollten, ist es tatsächlich die einzige Wahl, die wir sinnvoll machen können, weil wir potenziell viele Entwickler und Entwicklerinnen haben, also eine höhere 3-, wenn nicht 4-stellige Zahl, die damit arbeiten müssen und tatsächlich ist es so, bevor du sämtliche Angular oder Vue-Ausnahmen irgendwie versuchst beizubringen, Gibt's für das Problem, was du lösen willst, eine Komponente, die du über npm installieren kannst und das Ding ist gegessen. Fertig.
Und dieser Zugang und dieses Ökosystem war es uns halt einfach wert und von dem profitieren wir gerade massiv.
Ha.

[40:49] Und das sind keine technischen Schulden? Ah natürlich. Was ist, wenn die Kreti und Pleti GmbH sagt, das supporten wir jetzt nicht weiter? Natürlich sind das technische Schulden, aber gegen die habe ich auch gearbeitet.
Ich habe die Architektur so gestaltet, dass wenn diese Kreti und Pleti GmbH jetzt sagt, das supporten wir nicht mehr, dann zieht das nicht das gesamte Produkt nach unten, sondern nur ein sehr stark isolierten kleinen Teil, den man austauschen kann. Okay, also in dem Fall ist es tatsächlich technische Schuld, so wie in der Finanz auch. Wir nehmen da eine Abkürzung, aber theoretisch hätten wir es uns auch ansparen können, sprich selbst bauen können. Ja, natürlich. Okay, ja gut, das ist halt valide. Es hört sich halt nur so an, wenn installiere ich das halt irgendwoher, dann denke ich halt irgendwie so, ja okay, und was ist dein Plan B? Nein, das stimmt. Vielleicht, also ich muss mal schauen, Ich würde da gerne mal ein bisschen in die Details gehen, aber das wäre einmal ein Podcast voll gewährt.
Da muss ich mal nachgucken, wie es bei uns in der Firma ausschaut, was wir schon alles – also wir sind ja am Stand heute mit der Aufnahme, deswegen traue ich mich auch so frei darüber zu reden – haben wir das ganze Ding öffentlich geschalten.
Das heißt, unser neues Designsystem, die Art, wie wir Applikationen entwickeln, das Toolkit etc. ist seit heute, seit heute, 9 Uhr morgens, öffentlich auf mperm.
Kann sich jeder runterladen, kann jeder damit arbeiten.

[42:12] Also einen Link reingeben, um Gottes Willen. Nein, da macht sich einer, dann gibt es kollektives Code-Review.
Das möchte ich eigentlich vermeiden.
Aber nein, natürlich, ich hau das, die Links rein.
Man braucht natürlich immer nur einen Account bei uns im Produkt.
Aber nichtsdestotrotz ist es eine recht fesche Angelegenheit geworden.
Und da kann ich gerne mal drüber reden. Also das ist wahrscheinlich ein bisschen ein anderer Approach zu dem Microfrontends-Thema oder Microservice-Thema generell.
Und ich finde es recht lässig.
Ja, dann sollten wir das tatsächlich mal in die Aufnahme aufnehmen.
Die Frage ist halt, wenn ich mir immer so stelle, irgendwie wir haben die neue Technologie und jetzt ist alles besser.
Ich hab da halt immer so einen Kausalitätszweifel. Einfach nur, weil, na ja, du schreibst das jetzt neu, das heißt, zum zweiten Mal hast du notwendigerweise was gelernt.
Ja.

[43:04] Selbst wenn du's mit dem alten Zeug neu geschrieben hättest, wär's besser geworden.
Und da rauszuquantifizieren, wie viel da der neuen Technologie geschuldet ist, unklar.
Ich glaub eh nicht, ich bin ja der Meinung, dass die Technologie ja nie das Ausschlaggebende ist, weil im Grunde funktioniert ja jede Technologie halbwegs okay.
Es kommt ja immer darauf an, wie sie eingesetzt wird, beziehungsweise wie nachher damit umgegangen wird.
Und ich glaube, das sind gerade die interessanten Punkte bei dieser Architektur, die wir gemacht haben.
Also dieses React-Frontend ist tatsächlich nur ein kleines Detail, ein sehr wichtiges Detail, weil das macht das ja auch am Ende.
Aber alle anderen Dinge, die dafür sorgen, dass das Produkt funktioniert und dass das Produkt was anzeigt und dass das Produkt mit Backends redet und dass das Produkt Routing übernimmt, also Well-Handling übernimmt.
Alle diese Dinge sind mit ganz simplen, einfachen, dummen JavaScript geschrieben, komplett frameworkfrei und auf Technologien, die teilweise 15 oder mehr Jahre alt sind.
Und das wird dann spannend, weil das ist ziemlich langweilig.
Das sind fade, erprobte Technologien, kein Bleeding Edge, ganz und gar nicht, ganz im Gegenteil. Das hätte man wahrscheinlich im IE9 auch häufig so hinbekommen.
Aber neu interpretiert und React wirklich nur auf die UI-Anzeige reduziert, nur auf.

[44:27] Kriegst du einen Button, zeigst du einen Graph.
Und dadurch ist die Wichtigkeit von dem Ding relativ überschaubar.
Natürlich ist es ein Effort, dass du sagst, du machst dort ein Design-System und eine UI und hin und her.
Na klar, aber wenn du jetzt entscheidest, dass ein anderes Framework wichtiger ist für oder dass du jetzt auf Web Components gehst oder was auch immer suchst dir aus, oder dass du die Renderei änderst von Client-Site auf Server-Site oder komplett egal, oder du publischst statische HTML-Seiten. Der Rest ist immer nur das Gleiche.
Du kannst einfach die nächste Technologie ohne mehr auf die bestehende integrieren, dann lässt du es ein bisschen nebenbei laufen und irgendwann ist das andere so weit, dass du mit dem anderen abfangen kannst. Das wäre so die Idee.
Aber wie gesagt, da bin ich eigentlich schon ziemlich im Detail drin.

[45:16] Ja, ich würd noch eben einen ganz kurzen Moment da drinbleiben wollen, weil nur eine Frage ich noch habe, nämlich die Dinger, die dann sozusagen jetzt sich explizit nicht in dem React befinden, welcher Art sind die?
Also, was ist da so rausgetrennt? Was wurde im Vergleich zu vorher reduziert, sodass das React jetzt nur der UI-Layer war?
Was war da vorher noch mit drin?
Naja, also so Dinge wie, ähm ...
UL-Handling ist ja so ein ganz ...

[45:43] Klassischer Aspekt, nicht? Also du hast einen Pfad und wirst auf Basis dieses Pfades UI anzeigen, das kannst du in React machen oder hey, auch nicht. Oder Dinge wie das gesamte User Management, Dinge wie, also wir haben eine Monitoring-Lösung, das heißt wir zeigen natürlich gewisse Ereignisse in einem gewissen Timeframe an. Wo kommt der Timeframe her? Also auch so globalen Applikations-State, der wird komplett separat davon gehandelt. Und halt am meisten und am wichtigsten, glaube ich, die Navigation zwischen Seiten. Wird komplett unabhängig von React gemacht.

[46:20] Also wir sehen die Navigation zu einer anderen Subseite als Aufgabe vom Stamm-Framework, nicht als Aufgabe von der UI. Also React gleichsam als Templatesprache?
Ja. Das Einzige, wo wir ein bisschen reinblieben, ist, dass wir sagen, natürlich, wir haben SDKs für die Daten, die halt Fetch-Calls abstrahieren, jetzt nix Aufregendes. Wir stellen aber einfach zur Convenience auch Hooks dazu bereit, weil halt tatsächlich mit asynchronen Daten in Reaktor arbeiten ein ziemlicher Rotz ist. Deswegen machen wir uns dort das Leben einfacher mit Custom-Hooks.
Ja, die dann aber sozusagen nur eine Fassade sind zu der von dir gerade beschriebenen daraus faktorisierten logik ganz genau ja das ist auch tatsächlich die das was ich auch für sehr wertvoll erachte also ich weiß ja nicht wie das geht aber ich stelle bei mir fest dass ich und zu einem gewissen grad unter react brain leide also das ist sehr leicht kommitten in diese Welt, wo du sagst, Herren, da ist es nur mehr Hooks und Components und Fertigwerte.

[47:22] Nicht nur das, ich finde vor allem, dass diese Denkkette dich heute auch andere Dinge infiziert.
Ja. Und je mehr ich das sozusagen aktiv wahrnehme, umso weniger nützlich finde ich das.
Und umso mehr gehe ich halt wirklich hin und versuche so wirklich, wenn ich was designe, was eine herausfaktorisierte Library ist, die wirklich so einen Job macht und die auch eine einfache JavaScript-Funktion sein könnte, wirklich hinzugehen und zu sagen, wie würde ich die bauen, im nächsten Schritt sie einsetzen würde in meinem React-Projekt.
Ich weiß, dass das geht, aber wie würde ich es denn machen, wenn das nicht so wäre?
Und das ist dann am Ende das Public Interface, für das ich mich entscheide.
Weil ansonsten nützt das halt eben nichts mit Abstraktion und Auftrennung oder so, wenn allein das Paradigma durch den menschlichen Faktor dann doch aus dem Frontend raus und in Backends und Services und so rein sickert.
Da stimme ich dir zu 100 Prozent zu.
Und tatsächlich ist halt auch unser Learning bei dem ganzen Ding, Du kannst immer nur eine Abstraktionsschicht zu React machen, so hat man es früher ja auch gemacht.
Wichtig ist, genau wie du es sagst, dass du einfach die Ebene drunter dir gut anschaust, dann hast du länger was davon, glaube ich.

[48:29] Ja, wo waren wir denn? Ich weiß nicht, ob die anderen Punkte so wirklich interessant sind.
Also tatsächlich TypeRoots hat sich wieder ein bisschen verändert.
Tatsächlich gibt es jetzt noch andere Pfade, in denen zur Module Resolution nachgeschaut werden kann und dann sind wir eigentlich schon in der Editor-Ära, wo wir sagen, hey, TypeScript in Verbindung mit VSCode kann jetzt wieder andere Dinge, wie zum Beispiel Linked Cursors für JSX.
Das heißt, du gibst halt bei einem offenen Span-Tag, löscht du Span und änderst das in einen Div, weil es semantisch korrekt ist, dann ändert sich der Closing-Tag gleich mit.
Sprich, was hat dem L-Editor seit 15, 20 Jahren eigentlich schon können, geht jetzt auch in JSX. Fantastisch.
Und ansonsten Optimierungen.

[49:17] Ja, würde ich sagen. Performance-Optimierung. Teilweise werden da sportliche Zahlen präsentiert, von wegen, dass es jetzt irgendwie von 45 Sekunden ist es jetzt irgendwie auf 0,4 Sekunden runter.
Da guckst du dir das Beispiel an und denkst dir, kein Wunder, dass das langsam war vorher, wenn das nicht optimiert war.
Es ist alles etwas edge-casig bei der Performance-Optimierung.
Aber hey, man weiß halt nicht, was man sich an Dependencies installiert, in denen das dann möglicherweise sich Bahn bricht. Genau, haben wir tatsächlich auch unbedingt den Fall gehabt. Sehr lustig. Kennst du SORT?
Die SORT-Bibliothek, ich glaube, über die haben wir schon mal gesprochen.
Die kenne ich und benutze ich fleißig.
Und wir haben tatsächlich einen Fall gehabt bei einem Entwickler bei uns, der hat eine Patch-Version verwendet, die irgendeine Regression im TypeScript-Compiler gehabt hat, wo das Interpretieren oder das Set-Info vom Schema 15 Minuten dauert hat.
Mit der Patch-Version drüber war es wieder kein Problem, mit der Patch-Version drunter auch nicht, aber in der Patch-Version war irgendeine blöde Regression drin, die den Compiler zum Durchdrehen gebracht hat.
Fantastisch. Und da freue ich mich natürlich über jede Optimierung, die irgendwie stattfindet.

[50:27] Und das ist natürlich wieder wertvoll, sich daran zu erinnern.
Semantic Versioning ist eine Absichtserklärung und nicht eine Beschreibung der Realität.
Ja, tatsächlich. Ja, natürlich. Was ist ein Bracking Change?
Ist eine Performance-Rekression, ein Breaking-Change.
Kommt eben auf die Sichtweise an.
Also, bei 15 Minuten würd ich schon sagen, dass das ein Breaking-Change ist.
Weil ich meine, das breakt mein Nervenkostüm, das breakt meine Hardware, wenn ich die gegen die Wand schleudere.
Ja, da bricht schon einiges, das stimmt schon.
Ja. Oh, wei. Ja, cool. So, wir sind reingedrungen.
Pass auf, jetzt sind wir noch nicht. Wir haben noch eine Frage.
Ja, genau, genau, genau, wir haben eine höhere Frage.
Genau. Der Marvin möchte nämlich gerne wissen, wie schaut's aus mit, äh, Nominal Typing in TypeScript?
Wird's das jemals geben?
Oder die Frage ist ja im Prinzip, glauben wir, dass auch eine Chance besteht, dass es das jemals geben wird?

[51:23] Wir sollten, glaub ich, erst mal kurz erklären, Nominal Typing, kurz, was das ist.
Und dann sagen wir mal beide erst mal, unabhängig voneinander, ob wir glauben, dass das jemals was wird.
Und dann reden wir drüber, okay?
Structural Typing heißt, wenn wir zwei Objekte haben und die haben die gleiche Struktur, irgendwie ein Objekt mit einem Feld, wo eine Zahl drin ist, dann, obwohl die, sagen wir mal, zwei Interfaces genügen, die diese Struktur beschreiben, werden diese Dinger gleich behandelt, weil, wenn es die gleiche Struktur hat, wird es als identisch behandelt, weil es gibt halt keinen wahrnehmbaren Unterschied.
Im Unterschied zu so gut wie jeder anderen Programmiersprache, wo es nach Identität geht, da wird nicht gefragt, was kannst du, sondern wo kommst du her, und dann wird der Standbeamt angeschaut, und wenn man dann weiß, aha, du kommst aus A, du kommst aus B, ihr beschreibt das Gleiche, aber ihr seid unterschiedlich, dann werden sie unterschiedlich behandelt.
So, in TypeScript ist alles strukturell und nicht nominal und die Frage ist jetzt, und die müssen wir jetzt beantworten erstmal mit ja oder nein, Glauben wir, Stefan, dass es jemals nominal typing in TypeScript geben wird?

[52:18] Willst du zuerst oder soll ich zuerst? Ich sag zuerst ja.
Ich glaube es besteht eine Chance, dass es das geben wird.
Ich sage es existiert schon. Nimm String Enums her, die sind nominal getypt. Problem gelöst.
Das ist eine Antwort, wie sie nur ein zweifacher TypeScript Buch Autor geben kann.
String Enums, klar, logisch. Ich glaube das Problem, das dort herrscht, ist, du hast zwei primitive Datentypen, die auf den gleichen Wertebereich zeigen, aber unterschiedlich zu interpretieren sind. Das macht jetzt in einer Objektstruktur kann man das relativ leicht umgehen, weil sie sind mit der Struktur vielleicht einzigartig genug, dass du jetzt nicht unbedingt einen nominellen Type brauchst. Aber natürlich, wenn du jetzt einen PIN-Code und eine Balance hast und beides zeigt auf den Number-Bereich, dann wäre es natürlich gut, wenn man da unterscheiden kann. Das ist immer so dieses eine Beispiel, das herumgereicht wird.
Und deswegen möchten Menschen Nominal Types. Sie sagen halt, sie möchten gewisse primitive Datentypen als nominell anzeigen und dann musst du wirklich exakt von diesem Typen sein, damit genau solche Fehler nicht passieren.
Das kann ich als nützlich sehen. Ich muss aber auch tatsächlich sagen, ich habe, also.

[53:30] Ich lese den Issue, ich verstehe das Problem, ich sehe den Vorschlag, dass dieses Unique-Schlüsselwort, das bei Symbol schon existiert, repurposed wird für genau diesen Fall. Da denke ich mir, das ist eine saubere Lösung.
Ich sehe auch, dass es ein sehr hoch gevoteter Issue ist. Ich sehe auch, dass das Ding seit gefühlt zwei Jahren auf der Roadmap ganz weit oben ist, im Sinne von schauen wir uns ganz, ganz gut an, ob wir das irgendwie integrieren können.

[53:57] Ich habe in den letzten drei Jahren noch nie einen nominellen Typ gebraucht. Nie.
In keiner Applikation, die ich geschrieben habe, weder im UI noch in Serverless, noch was auch immer.
Das ist ein gutes Argument.
Auch wenn ich es verstehe und auch wenn ich sehe, was dort passiert, glaube ich, ist es nicht so wichtig, wie es beschrieben wird. Weil es gibt immer einen Weg, dass du die API anders gestaltest.
Es gibt immer einen Weg, dass du das Idiomatische zu dem machst, wie es sonst in JavaScript gearbeitet, wird. Und ich glaube, dass es ein falscher Freund ist, wenn du jetzt sagst, ja, du brauchst das jetzt unbedingt, ansonsten kommst du in lauter Probleme nah. Brauchst nicht.
Aber Stefan, die Frage ist doch nicht, ob du glaubst, ob es nützlich ist, sondern die Frage ist, ob du glaubst, dass es jemals in TypeScript landet.
Also ich hätte vor zwei Jahren noch gesagt ja, weil es ist tatsächlich auf der Future Listen und es war ein sehr aktiver Issue und normalerweise hört das TypeScript Team sehr stark drauf.
Mittlerweile denke ich mir, vielleicht irgendwann, aber ich bin mir da nicht mehr so sicher, weil ich glaube, dass die Reality-Checks den Issue intern auf der Typescript-Roadmap sehr weit nach unten drücken.

[55:09] Aber hey, vielleicht sag ich das jetzt in 5.2, ist dann endlich da, who knows.
Ich hab auch so Sachen wie die String-Template-Literal-Types nicht um die Ecken gekommen gesehen.
Also ...
Ja gut, die kamen auch wirklich aus dem Nichts, muss man ja mal sagen.
Plötzlich hieß es, hier ist der Pull-Request mit den Dingern.
Übrigens ein viel wichtigeres Feature, die String-Template-Literal-Types, wenn man sagt, Täter willst einen String haben, der ein gewisses Pattern befolgt.
Tausendmal besser als wie ein nomineller Type.
Ja, also meine Begründung, warum ich sage, es besteht eine Chance, dass das reinkommt, ist einfach, alles, was du im Prinzip gesagt hast, nur ich schneide halt den String von deiner Aussage bei dem Aber ab.
Ja. Also, weil es auf der Roadmap ist seit Ewigkeiten offen als Issue, ist nicht nur der meistkommentierteste, sondern ist halt eben auch schon sehr, sehr alt und gibt ja nicht viele Feature-Requests aus der Zeit von 2014, die halt noch offen gelassen werden.
2014?

[56:05] Ja, ja, 23. Juli 2014, 475 Kommentare. Dann kommt der 10-Jährige, ich glaub, den Humor hauens.
Ja, es ist absolut möglich.
Also, ich bin eigentlich im Prinzip bei dir.
Nur halt ist meine, würde ich halt eben sagen, obwohl ich mitgehe und sage, da brauchst du nicht, das ist gar nicht so dringend und bla, Keks, kann ich mir trotzdem vorstellen, dass das kommt, einfach nur weil das halt irgendwann auch ein offensichtliches Feature ist, jetzt Microsoft bist, quartalsweise es hinkriegen, dass Leute sich in Podcasts setzen und im Prinzip unbezahlte PR für Microsoft betreiben. Und dazu brauchst du Feature-Listen, damit sich dir das lohnt.
Ja gut, da haben aber die Leute noch nie in unsere Podcast-Episode direkt gehockt.
Wegen der unbezahlten Werbung, ne?
Ja, ist ja ein bisschen zugespitzt. Aber du willst halt trotzdem vierteljährlichen Release haben, in dem halt idealerweise mehr drinsteht, als in den Releases, die jetzt Jackvery heutzutage hat.
Das stimmt. Die haben da ja ein ganz anderes Interesse daran.
Apropos JQuery, da möchte ich einmal schauen, was der letzte Release war.
Oh, der war doch gar nicht so lange her, oder?
Ich nutze tatsächlich JQuery wieder. Es ist unbeschreiblich, wie schnell man eine Lösung hat, wenn man einfach sagt, man nimmt JQuery und zwar Plugins und weiß, wie man den DOM auszeichnen muss.
Fantastisch. Okay.
Ja. Nein, ich habe für die Björn Tellerrand diese Twitter-Wahl gemacht und die habe ich mit JQuery-Plugins gemacht. Huh.

[57:31] Ja gut, wenn es funktioniert. Also ursprünglich habe ich es gemacht für die Skript-Conf 2019.
Da haben wir gesagt, hey Mist, wir brauchen nur eine Twitter-Wahl, wo die Sprecherkarten so durchrotieren und die Sponsoren durchrotieren.
Und ich habe noch 30 Minuten gehabt vor der Konferenz, da habe ich gesagt, passt, Notebook auf, JQuery an, Grid-Layout, fertig.
Ja gut, das hätte ich, glaube ich, auch JQuery genommen. wenn ich das noch in meinem aktiven Speicher drin gehabt hätte.
Ich weiß gar nicht, ob ich drauf gekommen wäre.

[58:04] Ich frage mich, ich weiß nicht mehr, wie ich es installiert habe.
Ob ich es einfach über CDN geholt habe, oder ob ich es tatsächlich runtergeladen habe. Ich weiß nicht mehr.
Spannend auf jeden Fall.
Ich würde noch eben kurz, wo wir gerade bei unbezahlter PR sind, ein Visual Studio Code Plugin pluggen wollen. Nämlich Pretty Typescript Errors.
Kommt ja relativ oft, dass Leute mir sagen, irgendwie, der TypeScript-Fehler, der ist so kompliziert.
Und die sind ja manchmal auch wirklich ziemlich kompliziert und lang.
Obwohl die Ursache meist relativ trivial ist, weil irgendwo eine Property fehlt, aber die fehlt halt irgendwie in einem Interface mit 1000 Zeilen, und da fehlen halt irgendwie drei raus, und aus Unterobjekten, Blackhex, kannst du halt nicht lesen.
Und Project Typescript Errors probiert, das halt eben aufzubereiten.
Und obwohl, wenn man sich mal die Readme von dem Projekt durchliest, die Aufgabe nahezu unmöglich ist, das zu machen, aus einer Reihe von Beschränkungen mit APIs und Konsorten, sind die Ergebnisse dann doch überraschend gut. Also finde ich schön.
Ich glaube das ist das, auf das wir hin müssen. Ein bisschen hübscher ist besser als gar nicht hübscher.
Also bin ich total dafür. Finde ich voll cool.

[59:13] Wirklich schönes Plugin. Das ist es.
Okay, dann plugge ich einfach noch was, bevor wir zum Ende kommen.
Und zwar, wo wir beim Thema Typescript sind, hab Blogpost geschrieben, warum man gegebenenfalls Funktionen, die einen unknown Parameter kriegen, überladen, sollte, mit einem Parameter, der nicht unknown ist, aus Gründen der Cross-Typescript-JavaScript User Experience für diejenigen, die das Zeug am Ende aufrufen.
Weiß nicht, ob das irgendwie etabliertes Pattern ist oder ob ich mir das gerade frisch ausgedacht habe und niemand außer mir macht das.
Aber ich habe es mal aufgeschrieben und würde auch das in die Show Notes packen.
Ich habe sowas ähnliches in dem, was ich jetzt in die Show Notes packen möchte.
Ich schreibe gerade mein zweites TypeScript Buch, das TypeScript Cookbook für O'Reilly.

[1:00:01] Also wenn TypeScript den fünften Lesson 50 Lessons gehabt hat, hat TypeScript das TypeScript Cookbook 100 Lessons, die komplett unterschiedlich sind zu den 50, die wir davor gehabt haben.
Und da rede ich tatsächlich auch über was Ähnliches.
Tatsächlich überlade ich aber nicht Interfaces, die unknown sind.

[1:00:18] Mit konkreten Typen, sondern ich überlade Interfaces, die any sind, mit unknown, damit du zum Beispiel, wenn du einen Fetch-Call machst, und du hast dann rest.json und kriegst halt dort ein any zurück, dass du nicht eine direkte Typzuweisung machen kannst.
Das heißt, du kannst auch nicht sagen, let persons ist PersonArray von dem Fetch.rest.json, sondern du bist gezwungen, entweder eine Typüberprüfung zu machen, oder eine Type-Research mit S-Person zu machen, damit du die Bruchstellen zwischen der Echtwelt und der Typwelt sichtbarer machst.
Das ist so die Herangehensweise da drinnen. Also du patchst im Prinzip das globale Interface von Fetch? Genau.
Also für eine Response in dem Fall. Geht auch mit Chosen Past zum Beispiel, gleiches Thema.
Gibt auch eine zurück, kannst genauso sagen, soll einen zurückgeben und dann musst du eine Type-Research machen und dann weißt du, dass es hier eine Bruchstelle gibt zwischen der Echtwelt und dem Rest.

[1:01:09] Und also das ganze Buch geht genau um dieses Navigieren zwischen was passiert in der Echtwelt, was passiert bei dir im Code, was ist sinnvoll, also was kann man machen, wenn man es ad abstrusum führen würde mit sehr, sehr hochkomplexen Conditional Types, Was ist sinnvoll für deinen Case? Wo ist vielleicht okay, dass du mal extrem der Type-Researcher reinschmeißt und du dich bewusst machst, dass dort jetzt Dinge passieren, die jetzt nicht im Sinne vom Typ-System sind oder nicht mit dem Verständnis des Typ-Systems übereinstimmen.
Und das sind 400 Seiten geworden und glaube ich hoffe ich sehr hilfreich für alle Menschen, die mehr mit TypeScript machen und die jetzt hoffen, dass sie genau diese Problemstellungen, wo man merkt, hey, da bricht es gerade ein bisschen und da ist meine Vorstellung von dem Ganzen nicht die, die Typescript hat, Hilfestellungen bereitstellt.

[1:01:56] Ich hoffe, das war jetzt der ganze Satz. Ich bin gerade durcheinandergekommen.
Aber ja, das war total super und der Satz ist auf jeden Fall durch den Typechecker durchgegangen. Prima.
Haben wir denn schon eine Webseite für das Buch, dass wir das verlinken können?
Ja, ich werde auf die O'Reilly-Seiten verlinken. Das ist jetzt zum Zeitpunkt, wo wir sprechen, ist es im Early-Release.
Das heißt, es geht nur über die Leseplattform von O'Reilly, aber es wird, wenn es soweit ist, gibt es...
Also ich glaube, wenn die Episode draußen ist, gibt es schon ein Release-Datum, man kann es vorbestellen.
Das sollte hoffentlich möglich sein.
Ich habe übrigens, was mich sehr freut, ich habe ein Papageianbuch.

[1:02:38] Das ist, das haben sie sich auch extra so ausgedacht. Aber der Papagei befindet sich noch in einem Zustand des Lebendigseins.
Ja, der ist noch lebendig.
Das wäre natürlich noch cooler gewesen, wenn sie keine X-Hallaugen gemacht hätten oder so.
Aber das würde dann vielleicht mehr Ort zu sein wie das Buchsignal, wenn einfach die Augen durchstreichen.
Ich wollte gerade sagen, das könntest du tatsächlich irgendwie noch so als Accessoire irgendwie so haben.
Also bei mir kriegst du ja einen Laptop-Sticker, wenn du den TypeScript-Workshop überstanden hast.
Hast. Bei dir konntest du ja wirklich welche produzieren, die einfach so zwei kleine X sind, die passen genau da drauf. Oder googly eyes. Na gut, du bräuchtest eigentlich eher so zugly eyes, damit die halt... Irgendwie bist du einer Puppen, wenn du das niederlegst, dann macht es die Augen zu. Fantastisch. Genau so machen wir das. Ja prima, Dann haben wir auch noch diese ganzen Eigenwerbungen reingebracht.
Hey, sie hatten was mit TypeScript zu tun. Ich denke, das ist okay.
Wunderbar, dann würde ich sagen, haben wir doch dieses Thema erschöpfend erörtert.
Ich würde sagen, wir hören uns spätestens wieder, wenn TypeScript uns Mitte der Version 5.2 beglückt, und wir wieder einen neuen Grund finden können, warum React doof ist und nach Lolo riecht.
Geil, genau.
Wir danken fürs Zuhören, bis zum nächsten Mal, tschüssi. Ciao.

[1:04:02] Music.

[1:04:24] Musik.